Storage Management Initiative Specification (SMI-S) is a storage standard developed by SNIA (Storage Networking Industry Association) and it uses CIM (Common Information Model) to manage storage devices (e.g., Storage area network devices, i.e., SAN devices) from multiple vendors. Each storage device has a profile in the SMI-S model that specifies classes available in that management model, objects associated with the classes, and/or the associations that are required to be traversed to get particular data associated with the storage device. For example, SMI-S includes profiles and sub-profiles for disk arrays, switches, storage virtualizers, host bus adapters, tape libraries, and/or other storage devices/systems.
An SMI-S profile associated with a storage device defines classes, attributes, associations, and/or intrinsic/extrinsic methods that may be used to perform a particular management function. SMI-S enables storage management applications, for example, an SRM (Storage resource management) application (or other management application) to support and manage various storage devices from different vendors using a standard interface based on the CIM protocol. An SRM application may communicate with the storage devices through their respective vendor-specific SMI-S providers/agents. A particular SMI-S provider/agent associated with a particular storage device may query the storage device for information associated with the objects, attributes, associations, and/or methods defined in the corresponding class/profile.
The CIM model in the SMI-S specification is interpreted differently by different vendors. Each different vendor of a storage device may have its own interpretation of the profile associated with the storage device and implementation of the classes defined in the profile. Typically, the vendors extend (inherit) the CIM classes to add their own additional attributes. Per the SMI-S standard, each class defined in the profile may include some mandatory attributes/methods and some optional attributes/methods. For example, for a disk array class, name and serial number may be mandatory attributes, wherein each vendor of the disk array may be required to define these attributes. However, each vendor may add different optional attributes, may have a different format for the name attribute, and/or may define associations differently, thereby making their interpretations of the profile different from one another.
An SRM application may comprise multiple low level DLLs for each storage device. For example, an SRM application may comprise a separate low level DLL for each vendor of a disk array (for example, to support each vendor's interpretation of the profile). Also, with respect to the versions of SMI-S, there may be different low level DLLs. The DLLs communicate with the SMI-S provider/agent associated with the storage device (e.g. disk array) to extract desired information from the storage device. In other words, the DLLs communicate with the SMI-S provider/agent that in turn queries the storage device for information associated with the objects, attributes, associations, and/or methods defined in the corresponding class/profile, and provides the retrieved information to the SRM application.
Managing multiple low level DLLs for each storage device in a storage area network is a cumbersome task. SMI-S versions may be periodically updated, introducing at least some changes to the CIM object model. For example, an updated SMI-S version may change classes, attributes, or other information specified in the CIM object model, resulting in the way SMI-S profiles are handled. In conventional systems, changes to the low level DLLs may need to be made according to the updated SMI-S version because the DLLs typically encode the CIM object model. In other words, each time an SMI-S version changes, the DLLs may have to be re-written because each DLL typically includes hard-coding that specifies or otherwise describes the CIM object model for its associated storage device. The need to update DLLs may be exacerbated because of code redundancy among different DLLs, making maintenance of the DLLs difficult. Apart from the code for handling SMI-S and the CIM object model, the different DLLs typically share common code with one another. Thus, maintaining various DLLs may become inefficient and problematic, especially given the wide range of different types/vendors of storage devices and updates to the SMI-S.
Another problem with conventional systems is that different types of protocols may not be managed efficiently. For example, some storage devices may use only SMI-S, only Simple Network Management Protocol (SNMP), only another protocol or combination of protocols. However, each type of protocol may be associated with respective DLLs, Management Information Bases, or other sources of information, further exacerbating the problem of maintaining different sources of information for managing storage devices.
Thus, what is needed is an efficient way of managing access to data from storage devices according to the SMI-S, SNMP, and/or other protocol or combination of protocols without the need to update DLLs or other sources of information used to access data from the storage devices. These and other drawbacks exist.